<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: Email Address to URL Transformation 1.0 - Draft 3</title>
<meta http-equiv="Expires" content="Sat, 28 Jun 2008 02:31:52 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="Email Address to URL Transformation 1.0 - Draft 3">
<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">D. Fuelling</td></tr>

<tr><td class="header">&nbsp;</td><td class="header">Sappenin Technologies</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">June 28, 2008</td></tr>
</table></td></tr></table>
<h1><br />Email Address to URL Transformation 1.0 - Draft 3</h1>

<h3>Abstract</h3>

<p>
				Email Address to URL Transformation (EAUT) defines a 
				mechanism for transforming an RFC2822 "addr-spec" email 
				address into an associated URL.  The transform options 
				outlined in this document are designed to be flexible 
				enough such that every DNS domain-owner can specify 
				unlimited email address to URL transformations that 
				services can easily discover and utilize in their 
				URL-based transactions.
			
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>

<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Requirements Notation<br />
<a href="#terminology">2.</a>&nbsp;
Terminology<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor2">2.1.</a>&nbsp;
Existing Terminology<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor3">2.2.</a>&nbsp;
New Terminology<br />

<a href="#anchor4">3.</a>&nbsp;
Protocol Overview <br />
<a href="#anchor5">4.</a>&nbsp;
Recommended Usage in OpenID Authentication 2.0<br />
<a href="#discovery">5.</a>&nbsp;
EAUT Discovery<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#obtaining-discovery-endpoint">5.1.</a>&nbsp;
Determining the EAUT Discovery Endpoint URL<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#discovered_info">5.2.</a>&nbsp;

Discovered Information<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">5.3.</a>&nbsp;
XRDS-Based Discovery<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#valid_service_type_elements">5.3.1.</a>&nbsp;
Valid Service Type Elements<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#extracting_auth">5.3.2.</a>&nbsp;
Extracting the EAUT Template or EAUT Mapping Service Endpoint URL<br />
<a href="#eaut_template_transformation">6.</a>&nbsp;
Transforming an Email Address using an EAUT Template<br />

&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_template_structure">6.1.</a>&nbsp;
EAUT Template Structure<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_template_validity">6.2.</a>&nbsp;
EAUT Template Validity<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#valid_eaut_template">6.2.1.</a>&nbsp;
Valid EAUT Template<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#invalid_eaut_template">6.2.2.</a>&nbsp;
Invalid EAUT Template<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_template_transform_procedure">6.3.</a>&nbsp;

EAUT Template Transform Procedure<br />
<a href="#eaut_mapping_transformation">7.</a>&nbsp;
Transforming an Email Address using an EAUT Mapping Service<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_mapping_service_query">7.1.</a>&nbsp;
EAUT Mapping Service Query<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_mapping_service_result">7.2.</a>&nbsp;
EAUT Mapping Service Result<br />
<a href="#anchor9">8.</a>&nbsp;
Security Considerations<br />

&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor10">8.1.</a>&nbsp;
Man-in-the-Middle Attacks<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#eaut_mapping_service_email_address_harvesting_attack">8.2.</a>&nbsp;
EAUT Mapping Email-Address Harvesting Attack<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#op_email_address_harvesting_attack">8.3.</a>&nbsp;
OP Email-Address Harvesting Attack<br />
<a href="#anchor11">9.</a>&nbsp;
Acknowledgements<br />
<a href="#anchor12">Appendix&nbsp;A.</a>&nbsp;

Examples<br />
<a href="#eaut_template_example">Appendix&nbsp;A.1.</a>&nbsp;
EAUT Template Examples<br />
<a href="#XRDS_Simple_Sample">Appendix&nbsp;A.2.</a>&nbsp;
XRDS Service Element Examples<br />
<a href="#eaut_template_sample_1">Appendix&nbsp;A.2.1.</a>&nbsp;
EAUT Template Service Element Example 1<br />

<a href="#eaut_template_sample_2">Appendix&nbsp;A.2.2.</a>&nbsp;
EAUT Template Service Element Example 2<br />
<a href="#eaut_template_sample_3">Appendix&nbsp;A.2.3.</a>&nbsp;
EAUT Template Service Element Example 3<br />
<a href="#eaut_mapping_query_example">Appendix&nbsp;A.3.</a>&nbsp;
EAUT Mapping Service Element Example<br />
<a href="#rfc.references1">10.</a>&nbsp;

Normative References<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
Author's Address<br />
</p>
<br clear="all" />

<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Requirements Notation</h3>

<p>

				The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
				"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
				"MAY", and "OPTIONAL" in this document are to be
				interpreted as described in
				<a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate 						Requirement Levels,&rdquo; .</span><span>)</span></a>
				.
			
</p>
<a name="terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>

<a name="rfc.section.2"></a><h3>2.&nbsp;
Terminology</h3>

<p>
				The terminology definitions are broken up into two
				sub-categories: Existing and New terminology.
			
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.&nbsp;
Existing Terminology</h3>

<p>
					The following terminology is specified in
					<a class='info' href='#OpenID.authentication-2.0'>OpenID Authentication 2.0<span> (</span><span class='info'>OpenID Foundation, &ldquo;OpenID Authentication 2.0 - Final,&rdquo; December&nbsp;2007.</span><span>)</span></a> [OpenID.authentication&#8209;2.0]
					, and is reproduced here for reference throughout
					this document.
				
</p>
<p>

					</p>
<blockquote class="text"><dl>
<dt>Relying Party:</dt>
<dd>
							RP. A Web application that wants proof that
							the end user controls an Identifier.
						
</dd>
<dt>OpenID Provider:</dt>
<dd>
							OP. An OpenID Authentication server on which
							a Relying Party relies for an assertion that
							the end user controls an Identifier.
						
</dd>
<dt>OP Endpoint URL:</dt>

<dd>
							The URL which accepts OpenID Authentication
							requests, obtained by performing discovery
							on the the User-Supplied Identifier. This
							value MUST be an absolute URL.
						
</dd>
<dt>Claimed Identifier:</dt>
<dd>
							An Identifier that the end user claims to
							own; the overall aim of the OpenID
							Authentication 2.0 protocol is verifying
							this claim. The Claimed Identifier is
							either:
							
<ul class="text">
<li>
									The Identifier obtained by
									<a href='http://openid.net/specs/openid-authentication-2_0.html#normalization'>normalizing</a>
									the User-Supplied Identifier, if it
									was an URL.
								

</li>
<li>
									The
									<a href='http://openid.net/specs/openid-authentication-2_0.html#canonicalid'>CanonicalID</a>
									, if it was an XRI.
								
</li>
</ul>
						
</dd>
</dl></blockquote><p>
				
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>

<a name="rfc.section.2.2"></a><h3>2.2.&nbsp;
New Terminology</h3>

<p>
					The following is new terminology for this 
					specification.
				
</p>
<p>
					</p>
<blockquote class="text"><dl>
<dt>Processing-Agent</dt>
<dd>
							An agent (e.g, a computer program) 
							attempting to perform an Email Address to URL 
							Transform operation.
						

</dd>
<dt>Email Address:</dt>
<dd>
							An RFC2822 "addr-spec" compatible email
							address that can be used in the Email
							Address to URL Transformation protocol. This
							address consists of a "local-part" and a 
							"domain" part, separated by an "@" sign.
						
</dd>
<dt>Discovery Endpoint URL:</dt>
<dd>
							A URL that can be dereferenced to obtain an
							XRDS-Simple document listing the supported
							transformation mechanisms for a particular
							email address. This URL is formed by taking
							the "domain" portion of a Email Address, 
							and following the steps outlined in
							<a class='info' href='#obtaining-discovery-endpoint'>Determining the EAUT Discovery Endpoint
								URL<span> (</span><span class='info'>Determining the EAUT Discovery Endpoint URL</span><span>)</span></a>

							.
						
</dd>
<dt>Email Address To URL Tranformation Mapping Service (EAUT Mapping Service)</dt>
<dd>
							A web-based service that accepts a
							particular Email Address, and
							returns a 302 redirect to an URL.
						
</dd>
<dt>EAUT Mapping Service Endpoint URL</dt>
<dd>
							A URL where a particular EAUT Mapping Service can
							be accessed.
						
</dd>
<dt>Email Address to URL Transformation Template (EAUT Template)</dt>

<dd>
							A URL, containing zero or more Wildcard
							Replacement Tokens.
						
</dd>
<dt>Wildcard Replacement Token</dt>
<dd>
							A string surrounded by an opening-brace and
							a closing-brace, in that order (such as
							[username]). The Wildcard Replacement Token
							is used inside of an EAUT Template to designate 
							how associated URLs are structured.
						
</dd>
</dl></blockquote><p>
				
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;

Protocol Overview </h3>

<p>
				</p>
<ol class="text">
<li>
						An Email Address is presented to the
						Processing-Agent.
					
</li>
<li>
						The Processing-Agent performs
						<a class='info' href='#discovery'>discovery<span> (</span><span class='info'>EAUT Discovery</span><span>)</span></a>

						on the Email Address and retrieves
						an XRDS-Simple document containing one or more
						values representing an EAUT Template
						and/or an EAUT Mapping Service Endpoint URL.
					
</li>
<li>
						(Optional) If an EAUT Template is found, it can be used to
						<a class='info' href='#eaut_template_transformation'>transform<span> (</span><span class='info'>Transforming an Email Address using an EAUT Template</span><span>)</span></a>
						the Email Address into an URL.
					
</li>
<li>
						(Optional) If an EAUT Mapping Service Endpoint is
						found, it can be used to query the EAUT Mapping
						Service to determine the URL associated with 
						the supplied Email Address.
					

</li>
<li>
						The resulting URL can then be used as an 
						equivalent identifier for the Email Address in 
						URL-based transactions.
					
</li>
</ol><p>
			
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
Recommended Usage in OpenID Authentication 2.0</h3>

<p>

				This protocol extension results in an OpenID Identifier
				that can be utilized by a Relying Party to initiate
				OpenID Authentication.

				<br />
<br />

				Traditionally, OpenID Authentication 2.0 allows a
				User-Supplied Identifier to be an Identifier that is
				presented by the end user to the Relying Party, or
				selected by the user at the OpenID Provider. During the
				initiation phase of the OpenID 2.0 Authentication
				protocol, an end user may enter either their own
				Identifier or an OP Identifier. If an OP Identifier is
				used, the OP may then assist the end user in selecting
				an Identifier to share with the Relying Party.
				<br />
<br />


				Using this extension, OpenID Relying parties can extend
				the definition of a User-Supplied Identifier to include
				an Email Identifier as follows:
				<br />
<br />

				A User-Supplied Identifier is an OpenID Identifier or
				Email Identifier that was presented by the end user to
				the Relying Party, or an Identifier selected by the user
				at the OpenID Provider. During the initiation phase of
				the protocol, an end user may enter either their own
				Identifier, an OP Identifier, or an Email Identifier. If
				an OP Identifier is used, the OP may then assist the end
				user in selecting an Identifier to share with the
				Relying Party. If an Email Identifier is used, this
				identifier will be transformed into its corresponding
				OpenID URL or OpenID XRI, and used as a traditional
				User-Supplied Identifier in OpenID 2.0 Authentication.

			

</p>
<a name="discovery"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
EAUT Discovery</h3>

<p>
				EAUT Discovery is the process by which a Processing
				Agent utilizes a Discovery Endpoint URL to look up
				("discover") the information necessary for transforming
				an Email Address into an URL. This protocol has only one 
				path through which to do discovery:
			
</p>
<p>
				</p>
<ol class="text">

<li>
						The
						<a class='info' href='#XRDS-Simple'>XRDS-Simple<span> (</span><span class='info'>Hammer-Lahav, Eran., &ldquo;XRDS-Simple 1.0,&rdquo; .</span><span>)</span></a> [XRDS&#8209;Simple]
						SHALL be attempted on the EAUT Discovery
						Endpoint URL. If it succeeds, the result is an
						XRDS-Simple document that contains the necessary
						information for the protocol to continue. If
						more than one applicable Service Element is
						returned in the XRDS-Simple document, the
						precedence rules defined in [XRI_Resolution_2.0]
						are to be applied.
					
</li>
</ol><p>
			

</p>
<p>
				If the XRDS-Simple protocol fails for any reason (e.g., no
				valid XRDS-Simple document is retrieved, or no valid
				<a class='info' href='#valid_service_type_elements'>Service Elements<span> (</span><span class='info'>Valid Service Type Elements</span><span>)</span></a>
				are found in the XRDS-Simple document), then discovery
				is considered to have failed for the supplied EAUT
				Discovery Endpoint URL.
			
</p>
<a name="obtaining-discovery-endpoint"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.&nbsp;

Determining the EAUT Discovery Endpoint URL</h3>

<p>
					In order to obtain a Discovery Endpoint URL from an
					Email Address, the following process MUST be followed:
				
</p>
<p>
					</p>
<ol class="text">
<li>
							Parse the Email Address using the
							"at sign" ("@" ASCII #40) as a delimiter.
							The result of this parsing operation SHOULD
							be two tokens, the second of which will be
							the "domain" of the Email Address as defined
							by RFC2822, section 3.4.1. (The first token
							will be the "local-part" as defined by
							RFC2822). The first token SHOULD be
							discarded, leaving the second token, which
							is the "domain".
							<br />
<br />

						
</li>
<li>
							Using the "domain" result from the first
							step, prepend the string "http://" to it.
							<br />
<br />

						
</li>
<li>
							The resulting URL is a valid EAUT Discovery
							Endpoint URL, and can be used to perform
							EAUT Discovery.
							<br />
<br />

						

</li>
<li>
							If EAUT Discovery is not successful on the
							EAUT Discovery Endpoint URL obtained in the
							step above (i.e., no XRDS-Simple document is
							found, or no valid Service Elements are
							found in the XRDS-Simple document), then a
							new URL should be assembled by starting with
							the "domain" result from the first step, and
							prepending the string "http://www." to it.
							<br />
<br />

						
</li>
<li>
							The resulting URL is a valid EAUT Discovery
							Endpoint URL and can be used to perform EAUT
							Discovery. If EAUT Discovery is again
							unsuccessful on this final Endpoint URL,
							then Email Address Transformation is not
							possible with the supplied Email Address.
							The Processing Agent SHOULD treat the
							supplied Email Address as it would any other
							invalid user-supplied identifier.
						
</li>
</ol><p>
				
</p>
<a name="discovered_info"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.&nbsp;
Discovered Information</h3>

<p>
					Upon successful completion of EAUT Discovery, the
					Processing Agent will have an XRDS-Simple document
					containing the Email Address to URL Transform Protocol
					version, as well as one or more of the following
					pieces of information:

					</p>
<ul class="text">
<li>EAUT Template
</li>
<li>EAUT Mapping Service Endpoint URL
</li>
</ul><p>

				
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3.&nbsp;
XRDS-Based Discovery</h3>

<p>
					If XRDS-Simple discovery was successful, the result will
					be an XRDS-Simple Document, which is defined in
					[XRDS-Simple]. This is an XML document with entries
					for services that are related to the Email Address.
				
</p>
<a name="valid_service_type_elements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>

<a name="rfc.section.5.3.1"></a><h3>5.3.1.&nbsp;
Valid Service Type Elements</h3>

<p>
						For non-normative examples of XRDS-Simple
						Service Elements supported by this protocol, see
						the
						<a class='info' href='#XRDS_Simple_Sample'>XRDS Examples<span> (</span><span class='info'>XRDS Service Element Examples</span><span>)</span></a>
						section.
					
</p>

<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.3.1.1"></a><h3>5.3.1.1.&nbsp;
Service Type: EAUT Template</h3>

<p>
							An EAUT Template element is an &lt;xrd:Service&gt; element
							with the following information:

							</p>
<ul class="text">
<li>

									An &lt;xrd:Type&gt; tag whose text
									content is
									"http://specs.openid.net/oeat/1.0/ett".
								
</li>
<li>
									An &lt;xrd:URI&gt; tag whose text
									content is an EAUT Template.
								
</li>
</ul><p>
						
</p>
<a name="anchor8"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.3.1.2"></a><h3>5.3.1.2.&nbsp;
Service Type: EAUT Mapping Service</h3>

<p>
							An EAUT Mapping Service element is an
							&lt;xrd:Service&gt; element with the
							following information:

							</p>
<ul class="text">
<li>
									An &lt;xrd:Type&gt; tag whose text
									content is
									"http://specs.openid.net/oeat/1.0/eatoid".
								

</li>
<li>
									An &lt;xrd:URI&gt; tag whose text
									content is an an EAUT Mapping Service 
									Endpoint URL.
								
</li>
</ul><p>
						
</p>
<a name="extracting_auth"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5.3.2"></a><h3>5.3.2.&nbsp;
Extracting the EAUT Template or EAUT Mapping Service Endpoint URL</h3>

<p>
						Once the Processing Agent has obtained an XRDS
						document, it MUST first search the document
						(following the rules described in
						[XRI_Resolution_2.0]) for either an EAUT Template or an 
						EAUT Mapping Service Endpoint URL. If neither of 
						these are found, then the EAUT protocol fails.
					
</p>
<a name="eaut_template_transformation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Transforming an Email Address using an EAUT Template</h3>

<p>
				In order to transform a Email Address into an URL, a Processing 
				Agent may utilize a valid EAUT Template. This section details
				the structure of the EAUT Template, as well as the steps necessary
				to transform an Email Address into an URL using an EAUT Template.
			
</p>

<a name="eaut_template_structure"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.&nbsp;
EAUT Template Structure</h3>

<p>
					An EAUT Template is an absolute URL that contains zero 
					or more Wildcard Replacement Fields, each of which are 
					textual character(s) surrounded by an opening-bracket 
					("[" ASCII #5B ) on the left, and a closing-bracket 
					("]" ASCII #5D) on the right.
					<br />
<br />

					As of this version of the Transform protocol, the
					only allowed replacement field is "username".
					<br />

<br />

					Because the "opening-bracket" and "closing-bracket"
					characters are prohibited by the URI syntax, these
					characters MUST be percent-encoded per section 2.1
					of the URI Specification before being included in an
					XRDS document.
				
</p>
<a name="eaut_template_validity"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.&nbsp;
EAUT Template Validity</h3>

<a name="valid_eaut_template"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.2.1"></a><h3>6.2.1.&nbsp;

Valid EAUT Template</h3>

<p>
						An EAUT Template is considered to be valid if it 
						is either a valid URL, or a URL with a Wildcard 
						Replacement Field as allowed by this protocol. 
						Currently, only the [username] Wildcard Replacement 
						Field is defined and allowed.
					
</p>
<a name="invalid_eaut_template"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6.2.2"></a><h3>6.2.2.&nbsp;
Invalid EAUT Template</h3>

<p>
						An EAUT Template is considered to be invalid if the 
						EAUT Template has any of the following properties:
						</p>

<ul class="text">
<li>
								It contains more than one of either kind
								of bracket.
							
</li>
<li>
								It contains an odd number of brackets.
							
</li>
</ul><p>

						An invalid EAUT Template MUST NOT be used in an Email
						Address Transform operation.
					
</p>
<a name="eaut_template_transform_procedure"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>

<a name="rfc.section.6.3"></a><h3>6.3.&nbsp;
EAUT Template Transform Procedure</h3>

<p>
					If the valid EAUT Template does not contain any Wildcard 
					Replacement Fields, then the transform is complete: The 
					EAUT Template is the URL, and this transform protocol ends.
					<br />
<br />

					However, if the EAUT Template does contain a Wildcard
					Replacement Field, then the following procedure is
					used to transform the Email Address into an URL using an 
					EAUT Template:
				
</p>
<p>
					</p>

<ol class="text">
<li>
							Tokenize the Email Address using the "at sign" 
							("@" ASCII #40) as a delimeter. The result of 
							this parsing operation SHOULD be two tokens, the 
							first of which will be the "local-part" of the Email
							Address as defined by RFC2822, section 3.4.1. 
							(The second token will be the "domain").
							<br />
<br />

						
</li>
<li>
							The EAUT Template should be percent-decoded per
							section 2.1 of the URI specification.
							Specifically, %5B should be decoded to be
							the opening-bracket, while %5D should be
							decoded to be the closing bracket, but only
							where these two characters surround a valid
							Wildcard Replacement String (such as
							"username").
							<br />
<br />

						
</li>

<li>
							Next, in the EAUT Template replace the portion of the
							EAUT Template that contains "[username]" (excluding
							single-quotes) with the value of the
							"local-part" portion of the email address.
							<br />
<br />

						
</li>
</ol><p>
				
</p>
<a name="eaut_mapping_transformation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
Transforming an Email Address using an EAUT Mapping Service</h3>

<p>
				In order to transform a Email Address into an
				URL, Processing Agents may utilize an EAUT Mapping Service. 
				This section details how Processing Agents can access such 
				service endpoints, and the expected results that MUST be
				returned.
			
</p>
<a name="eaut_mapping_service_query"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.&nbsp;
EAUT Mapping Service Query</h3>

<p>
					In order to query an EAUT Mapping Service, a Processing
					Agent SHOULD issue an HTTP GET request on the EAUT Mapping
					Service's Endpoint URL. The GET request must contain
					an attribute named "email", with the Email Address as the 
					value of this attribute. If more than one "email" 
					attribute is specified in the GET query, then EAUT Mapping 
					Service Endpoints SHOULD utilize only the first attribute 
					in the query string. See Appendix A.4 for a non-normative 
					example of an EAUT Mapping Service Query.
				
</p>

<a name="eaut_mapping_service_result"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.&nbsp;
EAUT Mapping Service Result</h3>

<p>
					After receiving an EAUT Mapping Service Query, an EAUT
					Mapping Service MUST return an HTTP 302 redirect to an 
					appropriately mapped URL.
				
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;

Security Considerations</h3>

<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.1"></a><h3>8.1.&nbsp;
Man-in-the-Middle Attacks</h3>

<p>
					If DNS resolution or the transport layer is
					compromised, this protocol is not fully secure since
					the attacker can impersonate the Discovery Endpoing URL 
					and tamper with the discovery process. If an attacker can 
					tamper with the discovery process he/she can specify any
					URL, and so does not have to impersonate the mapped URL.
					Additionally, if an attacker can compromise the
					integrity of the information returned during the
					discovery process, by altering the XRDS document,
					the need for a man in the middle is removed. In such
					an attack, a forged EAUT Template or forged EAUT Mapping 
					Service Endpoint URL could be returned. One method to 
					prevent this sort of attack is by digitally signing the 
					XRDS file as per <a class='info' href='#RFC3275'>XMLDSIG<span> (</span><span class='info'>Eastlake 3rd, D., Reagle Jr., J., and D. Solo, &ldquo;(Extensible Markup Language) XML-Signature 						Syntax and Processing,&rdquo; .</span><span>)</span></a> [RFC3275].
					The keying material is not specified, since the Processing 
					Agent ultimately needs to make its own decision whether to
					trust keys used for such a signature.
				

</p>
<p>
					Using SSL with certificates signed by a trusted
					authority prevents these kinds of attacks by
					verifying the results of the DNS look-up against the
					certificate. Once the validity of the certificate
					has been established, tampering is not possible.
					Impersonating an SSL server requires forging or
					stealing a certificate, which is significantly
					harder than the network based attacks.
				
</p>
<p>
					In order to get protection from SSL, SSL must be
					used for all parts of this protocol, While the
					protocol does not require SSL be used, its use is
					strongly RECOMMENDED. Current best practices dictate
					that Discovery Endpoint URL SHOULD use SSL, with a 
					certificate signed by a trusted authority, to secure its 
					Endpoint URL as well as the interactions with the Processing
					Agent.  Following its own security policies, a Processing
					Agent MAY choose to not complete, or even begin, a 
					transaction if SSL is not being correctly used at the
					Discovery Endpoint URL.
				
</p>
<a name="eaut_mapping_service_email_address_harvesting_attack"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.2"></a><h3>8.2.&nbsp;
EAUT Mapping Email-Address Harvesting Attack</h3>

<p>
					EAUT Mapping Service Endpoints may be prone to an email
					address harvesting attack if the EAUT Mapping Service
					returns different HTTP codes for different email
					addresses. For example, if an EAUT Mapping Service
					determines that a particular email address is not
					actually in use, and then returns a special result
					message to indicate this, an attacker could utilize
					this information in order to determine if a
					particular email address is valid or not for a
					particular domain.

					Thus, in order to reduce the risk of email address
					harvesting attacks, an EAUT Mapping Service should always
					redirect to a well-formed URL, even if the system is
					unable to verify that supplied email address actually 
					corresponds to a valid user.  In this way, an attacker 
					will not be able to determine if a particular email 
					address is actually registered with the EAUT Mapping 
					Service.
				
</p>
<a name="op_email_address_harvesting_attack"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8.3"></a><h3>8.3.&nbsp;
OP Email-Address Harvesting Attack</h3>

<p>
					OP's should be careful to always resolve a
					particular OpenID URL, even if that OpenID URL is
					not a valid OpenID in the OP system. If a particular
					OP does not resolve *all* OpenID Identifier URL's,
					then an email address harvesting attack could
					utilize an EAUT Service Endpoint to determine which
					email addresses correspond to valid OpenID
					Identifiers, thus increasing the value of harvested
					email addresses. This recomendation holds true
					outside of this specification, although it is
					highlighted here because EAUT can exacerbate this
					problem by possibly connecting an email address to a
					particular OpenID Identifier URL.
				
</p>
<a name="anchor11"></a><br /><hr />

<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.&nbsp;
Acknowledgements</h3>

<p>
				Textual portions of the OpenID Authentication 2.0 and
				XML portions of the OpenID Attribute Exchange 1.0
				specifications were used in the creation of this
				extension document.
			
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
Examples</h3>

<p>Non-normative
</p>
<a name="eaut_template_example"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.1"></a><h3>Appendix A.1.&nbsp;
EAUT Template Examples</h3>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://[username].example.com/</pre></div><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>https://www.example.com/server/[username]</pre></div>
<a name="XRDS_Simple_Sample"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2"></a><h3>Appendix A.2.&nbsp;

XRDS Service Element Examples</h3>

<a name="eaut_template_sample_1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2.1"></a><h3>Appendix A.2.1.&nbsp;
EAUT Template Service Element Example 1</h3>

<p>
							For an Email Address "beth@example.com" to 
							transform to the URL "https://beth.example.com", 
							the following XML snippet should be present in
							the the XRDS file when discovery is preformed on 
							"https://example.com/" or "https://www.example.com":
						
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;

  &lt;Type&gt;http://specs.openid.net/oeat/1.0/ett&lt;/Type&gt;
  &lt;URI&gt;https://%5Busername%5D.example.com/&lt;/URI&gt;
&lt;/Service&gt;

</pre></div>
<a name="eaut_template_sample_2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>

<a name="rfc.section.A.2.2"></a><h3>Appendix A.2.2.&nbsp;
EAUT Template Service Element Example 2</h3>

<p>
							For an Email Address "beth@example.com" to 
							transform to the URL
							"https://www.example.com/openid/personas/beth",
							the following XML snippet should be present
							in the the XRDS file when discovery is
							preformed on "https://example.com/" or
							"https://www.example.com":
						
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;
  &lt;Type&gt;http://specs.openid.net/oeat/1.0/ett&lt;/Type&gt;

  &lt;URI&gt;https://www.example.com/openid/personas/%5Busername%5D/&lt;/URI&gt;
&lt;/Service&gt;

</pre></div>
<a name="eaut_template_sample_3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.2.3"></a><h3>Appendix A.2.3.&nbsp;
EAUT Template Service Element Example 3</h3>

<p>
							For all Email Addresses "*@example.com" to 
							use the URL "https://www.example.com/",
							the following XML snippet should be present
							in the the XRDS file when discovery is
							preformed on "https://example.com/" or
							"https://www.example.com":
						
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

&lt;Service xmlns="xri://$xrd*($v*2.0)"&gt;
  &lt;Type&gt;http://specs.openid.net/oeat/1.0/ett&lt;/Type&gt;
  &lt;URI&gt;https://www.example.com/&lt;/URI&gt;

&lt;/Service&gt;

</pre></div>
<a name="eaut_mapping_query_example"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.3"></a><h3>Appendix A.3.&nbsp;
EAUT Mapping Service Element Example</h3>

<p>
						The following is an example HTTP GET request
						that could be made to an EAUT Mapping Service 
						Endpoint URL  to determine the URL for 
						an Email Address of "beth@example.com".
					
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

GET /eaut_mapper/?email%3Dbeth@example.com HTTP/1.1
Date: Wed, 08 Jun 2008 04:06:18 GMT
Host: example.com

</pre></div>
<p>
						The following is an example response containing 
						a 302 redirect code for the above reqest:
					
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>

HTTP/1.1 302 Found
Location: http://openid.example.com/people/beth

</pre></div>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>10.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="ASCII">[ASCII]</a></td>

<td class="author-text">The Unicode Consortium, &ldquo;<a href="http://www.unicode.org/charts/PDF/U0000.pdf">The ASCII subset of the Unicode Standard 5.0</a>.&rdquo;</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.authentication-2.0">[OpenID.authentication-2.0]</a></td>
<td class="author-text"><a href="mailto:specs@openid.net">OpenID Foundation</a>, &ldquo;OpenID Authentication 2.0 - Final,&rdquo; December&nbsp;2007 (<a href="http://openid.net/specs/openid-authentication-2_0.txt">TXT</a>, <a href="http://openid.net/specs/openid-authentication-2_0.html">HTML</a>).</td></tr>

<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, S., &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate
						Requirement Levels</a>,&rdquo; RFC&nbsp;2119.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, &ldquo;<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,&rdquo; RFC&nbsp;2616.</td></tr>

<tr><td class="author-text" valign="top"><a name="RFC2822">[RFC2822]</a></td>
<td class="author-text">Resnick, P., &ldquo;<a href="http://tools.ietf.org/html/rfc2822">Internet Message Format</a>,&rdquo; RFC&nbsp;2822.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3275">[RFC3275]</a></td>
<td class="author-text">Eastlake 3rd, D., Reagle Jr., J., and D. Solo, &ldquo;<a href="http://tools.ietf.org/html/rfc3275">(Extensible Markup Language) XML-Signature
						Syntax and Processing</a>,&rdquo; RFC&nbsp;3275.</td></tr>

<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text">Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic
						Syntax</a>,&rdquo; RFC&nbsp;3986.</td></tr>
<tr><td class="author-text" valign="top"><a name="XRDS-Simple">[XRDS-Simple]</a></td>
<td class="author-text">Hammer-Lahav, Eran., &ldquo;<a href="http://xrds-simple.net/core/1.0/">XRDS-Simple 1.0</a>.&rdquo;</td></tr>
<tr><td class="author-text" valign="top"><a name="XRI_Resolution_2.0">[XRI_Resolution_2.0]</a></td>

<td class="author-text">Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, &ldquo;<a href="http://www.oasis-open.org/committees/download.php/17293">Extensible Resource Identifier (XRI) Resolution
						V2.0 - Working Draft 10</a>&rdquo; (<a href="http://www.oasis-open.org/committees/download.php/17293">PDF</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="XRI_Syntax_2.0">[XRI_Syntax_2.0]</a></td>
<td class="author-text">Reed, D. and D. McAlpin, &ldquo;<a href="http://www.oasis-open.org/committees/download.php/15376">Extensible Resource Identifier (XRI) Syntax V2.0</a>&rdquo; (<a href="http://www.oasis-open.org/committees/download.php/15376">HTML</a>, <a href="http://www.oasis-open.org/committees/download.php/15377">PDF</a>).</td></tr>

</table>

<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">David Fuelling</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Sappenin Technologies, LLC</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Salt Lake City, UT  84117</td></tr>

<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:sappenin@gmail.com">sappenin@gmail.com</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://www.sappenin.com">http://www.sappenin.com</a></td></tr>
</table>
</body></html>
